home *** CD-ROM | disk | FTP | other *** search
/ Night Owl 6 / Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso / 015a / qw12inst.zip / EXCEPT13.TEC < prev    next >
Text File  |  1991-03-14  |  8KB  |  156 lines
  1. ID:13 Exception #12 and #13 and QEMM 
  2. Quarterdeck Technical Note #142
  3. by Bob Perry and Dan Sallitt
  4.  
  5. Q: What is an "Exception #12"?  What is an "Exception #13"?       
  6.                     
  7.  
  8. Q: What can be done to prevent Exception #12's and #13's?
  9.  
  10.      Exceptions are unusual or invalid conditions associated with 
  11. the execution of a particular instruction by the 80386 processor 
  12. (or higher processors).  The 80386 recognizes several different 
  13. classes of exceptions, and assigns a different vector number to 
  14. each class. The DESQview-386 memory manager, QEMM-386, has been 
  15. designed to capture these 80386 exception vectors and display 
  16. them directly to the user.
  17.  
  18.     Exception #13 is the "General Protection Fault" error.  Any 
  19. privileged instruction or any instruction that references memory 
  20. can trigger an Exception #13.  It is the most commonly 
  21. encountered 80386 fault.
  22.  
  23.     The two circumstances that can cause an Exception #13 to 
  24. occur require very different troubleshooting approaches.  In the 
  25. first case, privileged instructions, the Exception #13 could 
  26. indicate that a program has violated the protected mode of the 
  27. 80386 by executing a privileged instruction or I/O reference. 
  28. Thus, when the prompt "Terminate, Reboot or Continue?" is issued, 
  29. the "Continue" option puts the system back into real mode, and 
  30. the program should continue to execute. (After choosing the 
  31. "Continue" option, one should not necessarily assume that the 
  32. system is stable.  A reboot at the earliest convenient time is 
  33. probably wise.)
  34.  
  35.      It is the second case, instructions that reference memory, 
  36. that is far more common to DESQview 386 (and QEMM-386) users.  
  37. Here the exception may indicate that an application has a bug, or 
  38. that adverse circumstances have sent it out of control.  It has 
  39. overwritten its memory partition, and may in fact be running 
  40. wild, executing meaningless code.  This situation can occur with 
  41. some programs that were written for use on the 8088 processor and 
  42. may not be usable in the 80386's virtual 8086 mode. 
  43.  
  44. A few other programs may not be compatible with QEMM-386.  In 
  45. some cases the problem occurs even without QEMM present (in which 
  46. case it manifests itself as a crash instead of an error
  47. message).  What this usually adds up to is that when "Terminate, 
  48. Reboot or Continue" is displayed, the user can usually only 
  49. "Terminate."
  50.  
  51.      On a technical level, this overwriting of the memory partition
  52. generally means that a word or a double word value has been 
  53. fetched from or written to the last byte of a segment.  The 
  54. problem or "bug" in the application program or in the system 
  55. shows up as an attempt to wrap the value to the next segment of 
  56. memory.
  57.  
  58.      What can the user do to prevent Exception #13's?   Because a 
  59. great many problems can result in Exception #13's, it is 
  60. sometimes necessary to resort to general troubleshooting 
  61. techniques.  The DESQview 386 user should start with two simple 
  62. steps: first, run Change a Program and try to allocate more 
  63. memory to the application.  Second, the user can try to increase 
  64. the protection level of the afflicted window to 3, which will not 
  65. remove the source of the Exception #13, but may pass more 
  66. descriptive error messages through to the user.  
  67.  
  68.      When Exception #13's are obtained outside of DESQview they 
  69. are either caused by applications written for the 80386 protected 
  70. mode or they are not.  If the faulting application is written for 
  71. the protected mode of the 80386, it is likely that this program 
  72. has no VCPI (Virtual Control Program Interface) support.  Since 
  73. QEMM-386 is a protected mode program, such faulting applications 
  74. cannot be run under QEMM without VCPI.  The user has no choice 
  75. but to reboot without QEMM, and contact the developer of the 
  76. faulting application to request VCPI support.
  77.  
  78.      If the faulting application was not written for the 
  79. protected mode of the 80386, a good possibility is that the QEMM 
  80. user has installed QEMM with the RAM parameter (which is 
  81. necessary to LOADHI drivers and TSR's).  In this case the 
  82. faulting program may be running in an area of high RAM that 
  83. contains a memory conflict.  To correct this problem, the user 
  84. may opt to RAM only specific areas of memory, as described on 
  85. page 6 of the QEMM-386 manual, rather than to RAM all mappable 
  86. areas.  Of course, an area of conflict that is not RAMmed is 
  87. still an area of conflict, and may cause problems if another 
  88. application tries to map expanded memory into that region.  A 
  89. better solution to such memory conflicts might be to use the 
  90. EXCLUDE parameter (described on page 5 of the QEMM manual) on the 
  91. area in conflict.  
  92.  
  93.      When in doubt about which areas to exclude, the user may 
  94. wish to pay special attention to areas that are marked "Rammable" 
  95. on the QEMM.COM Type screen, or to High RAM areas in the F000-
  96. FFFF area.  "Rammable" areas are usually adjacent to ROM areas, 
  97. and the possiblilty exists that the ROM is slightly bigger than 
  98. QEMM could detect and is spilling over into the "Rammable" area.  
  99. High RAM areas in the F000-FFFF region are mapped over pieces of 
  100. the system ROM that either QEMM or the user have judged not to be 
  101. in use.  Obviously, this judgment should be questioned when 
  102. Exception #13 messages occur.  The F000-FFFF area should be 
  103. scrutinized especially carefully when floppy disk access 
  104. generates the exception error. 
  105.  
  106.      The QEMM.COM Accessed screen (also available as the Manifest 
  107. QEMM-386\Accessed screen) can give the user valuable hints about 
  108. what areas of memory are in use.  To use the Accessed screen, 
  109. replace the RAM parameter on the QEMM line in the CONFIG.SYS file 
  110. with the ON parameter and reboot the machine.  Any area that the 
  111. Accessed screen then shows as having been touched, but that the 
  112. Type screen shows as Mappable or Rammable, is a good candidate 
  113. for exclusion.  If the Exception #13 error only occurs with the 
  114. RAM parameter present, you can now safely perform the action that 
  115. usually generates the error, then consult the Accessed screen to 
  116. see what areas of memory have been newly touched. 
  117.  
  118.     Some pieces of hardware can come into conflict with QEMM or 
  119. DESQview and generate Exception #13 errors.  The most frequent 
  120. offenders are bus-mastering devices (hard disk controllers, 
  121. network cards, CD-ROM controllers, etc.) and autoswitching video 
  122. cards.  Bus-mastering hard disk controllers often cause Exception 
  123. #13 errors upon any use of the LOADHI programs, for instance.  
  124. For approaches to this problem, see the Quarterdeck Technical 
  125. Note titled "Bus-Mastering Devices and QEMM-386."  Not all 
  126. autoswitching video cards come into conflict with QEMM or other 
  127. pieces of software.  When a conflict occurs, however, it does not 
  128. always take the form of a video problem, and sometimes results in 
  129. the Exception #13 message.  Disabling autoswitching is the only 
  130. solution to such a problem.
  131.  
  132.     General troubleshooting methods, like temporarily removing 
  133. all TSR's, device drivers and questionable QEMM parameters, often 
  134. provide valuable information about the exception error.  It 
  135. sometimes happens that a circumstance that generates an Exception 
  136. #13 with QEMM present simply causes the machine to crash without 
  137. any message when QEMM is removed.  In such a case, QEMM is simply 
  138. the bearer of bad news.
  139.  
  140.      Exception #12 is the "Stack Segment" fault.  The stack 
  141. segment fault occurs when the processor detects certain problems 
  142. with the segment addressed by the SS segment register.  This 
  143. exception too can be the result either of a bug in a program or 
  144. of some system malfunction that eventually results in a stack 
  145. error. All of the above methods of troubleshooting Exception #13 
  146. messages should also be used when trying to track down the cause 
  147. of an Exception #12.  The one difference that should be kept in 
  148. mind is that Exception #12 messages are not generated by an 
  149. application simply going into protected mode, executing 
  150. privileged instructions, or accessing privileged registers.  
  151. Therefore you need not consider the possibility that the 
  152. application needs to incorporate VCPI support to run with QEMM.
  153.  
  154.         Copyright (C) 1991 by Quarterdeck Office Systems
  155.              * * *   E N D   O F   F I L E    * * * 
  156.